Enter your search text in the box above

Select a result to preview

Build to Delete 与 Build to Last — Agent 系统的两种设计姿态

#type/article #area/ai #area/architecture

一个被忽略的设计问题

讨论 Agent 系统设计时，大多数对话集中在"该加什么"——加 planner、加 evaluator、加 memory、加 RAG。框架在膨胀，组件在堆积，架构图越来越像微服务拓扑。

很少有人问反向的问题：哪些组件将来该被拆掉，哪些不该？ 不是"这个组件有没有用"——有用的组件太多了。问题是，在它被创建之前，设计者是否知道它属于"将来会被拆"那一类，还是"会持续存在"那一类？

这两类的设计姿态应该完全不同。但大多数 Agent 系统的构建者没有在做这个区分。

Anthropic 在 2026 年 3 月公开了一个答案。

Anthropic 拆掉了什么

Prithvi Rajasekaran 的团队在将多 Agent Harness 从 Claude Opus 4.5 迁移到 4.6 时，系统性地拆除了三个组件：Sprint 分解、Context Reset、逐轮 Evaluator。

这不是重构。重构是用更好的设计替代旧的设计。这里发生的是拆除——组件不是被更好的版本替代的，是被证明不再必要后直接移除的。

每个被拆的组件都编码了一个对"模型此时做不到什么"的假设：

组件 编码的假设 为什么在 4.6 下不再成立
Sprint 分解 模型无法在长会话中保持连贯 4.6 能连续编码 2h+ 不跑偏
Context Reset 上下文快满时模型会过早草草收工 该行为在 4.5 已消失
逐轮 Evaluator Generator 每轮输出都需要外部检查 Generator 能力提升后，大量原本需要检查的问题自己能处理

结果：从 6 小时 / $200 降到 3.8 小时 / $125。不是因为跑得更快——是因为跑得更少。

方法论也值得注意：逐个移除，测量影响。 不是靠直觉判断哪个组件还有用。是做减法实验。Sprint 移除后 Builder 仍能产出→保留移除。Planner 移除后方向失控→恢复。Evaluator 完全移除后质量下降但不需要每轮都跑→降级为最终单次 QA。

Lance Martin 在《Harnessing Claude's Intelligence》中将这提炼为更根本的问题：不是"还能加什么"，而是**"我可以停止做什么"**。

但 Anthropic 的案例只讲了故事的一半。它回答了"哪些组件该拆"，没有回答"哪些组件不该拆，以及为什么"。

模型是大脑，Harness 是手脚

要回答这个问题，需要先理解模型和 Harness 之间的分工本质。

模型只做一件事：输出 token。它不能写文件，不能调 API，不能感知时间流逝，不能记住上一轮对话中发生过什么——除非有人把这些能力接给它。模型是一颗脱离身体的大脑，功能完整但没有手脚。

Harness 提供的不是一种东西，是两种完全不同的东西：

思维补偿 行动接口
做什么 帮助模型思考：规划、拆解、约束、评估 让模型能行动：持久化、I/O、工具调用、消息路由
存在原因 模型当前的推理能力不足 模型结构上就没有手脚
随模型升级 被逐步拆除 不会因模型升级而拆除
设计姿态 Build to Delete Build to Last

Sprint 分解是思维补偿——假设模型无法在长会话中保持连贯，所以需要外部切分。被拆了。

但文件系统接口不会因为模型从 4.5 升级到 4.6 而被拆除。不是因为模型不够聪明——无论多聪明，模型都不能自己写磁盘。这是结构性鸿沟，不是能力问题。大脑不能动手，这是本体论上的限制，不是当前版本的限制。

思维补偿层：半衰期在缩短

思维补偿层的组件编码了"模型还做不到 X"的假设。规划、任务分解、逐步骤验证、约束提示——它们的存在前提会随每次模型升级被重新评估。

Boris Cherny 的 CLAUDE.md 只有几行，频繁裁剪。他的原则是刻意不为今天的模型构建，而为六个月后的模型构建——Claude Code 的代码库几乎没有超过六个月的代码行。这不是极简主义审美，是对模型能力曲线的理性预期。

值得强调的是规模不是判断标准。一个三行的约束 prompt 和一个多 Agent 编排管线——只要它们在做的是补偿模型的推理局限——都属于这一层。一个复杂系统完全可以被设计成 build to delete 的，前提是每个组件都有明确的退出条件和独立的可拆除性。

这要求设计者从一开始就按"可拆卸"来构建：模块化、松耦合、组件间通过文件而非内存传递状态，每个组件能独立测试，也能独立移除而不波及其他部分。不是因为它们不重要——恰恰因为它们在某一天会变得不重要。

行动接口层：为什么 Build to Last

行动接口层连接的是模型与现实之间的结构性鸿沟。模型只会输出 token，而现实世界有文件系统、数据库、API、传感器、用户输入。这个鸿沟不会因为推理能力变强而消失——它不是能力问题，是本体论问题。

持久化机制、消息管道、外部工具调用协议——这些东西会持续存在。不是"不拆"，而是拆了之后需要立刻重建功能等价的东西。

这层组件的设计姿态不是临时代码，而是稳定的接口。稳定不意味着复杂——恰恰相反，行动接口最有价值的属性是简单和可替换。

Script-as-Pipeline — Agent 管线中的脚本节点设计模式 中讨论的 stdout 作为管线节点，就是一个典型的行动接口设计。脚本的 stdout 被注入到 agent 上下文——这不是在帮模型思考，而是在为模型提供一个确定性、可测试、和 prompt 解耦的通信通道。它不依赖"模型能不能理解这行输出"——理解力会随模型升级而变化。它依赖的是"这条通道是否可靠"——这是接口质量，和模型能力无关。

Build to Last 也在被挑战——但不是因为模型变强

行动接口的"Last"不意味着不变。只是变化的动力不同。

思维补偿层的变化动力是模型能力提升——组件被拆除，因为模型不再需要它。行动接口层的变化动力是构建成本在指数下降。

一个文件系统适配器以前需要手写几百行、写测试、处理边界条件。现在一个合格的 spec 加上 4.6 级别的模型可以在几分钟内生成、验证、适配。所以行动接口虽然不会因模型升级而被拆，但会被更频繁地以更低成本重建。

"Last" 的时长在缩短——不是因为接口的需求变了，而是因为重建成本降到了不值得忍受旧设计的程度。一个构建成本 $50 的组件不再值得维护两年——重建一个更便宜。

这意味着行动接口层的最优策略不是"建一次用很久"，而是"保持足够简单，以便在重建成本低于维护成本时毫不犹豫地替换"。设计目标从耐久性变成了可替换性。

对设计者的意义

在动手设计一个 Agent 系统前，对每个计划中的组件回答一个问题：它补偿的是模型的思维缺陷，还是填补的是模型的行动能力缺口？

两种姿态的混淆是 Agent 系统中最常见的隐性成本。把思维补偿当成永久架构——结果是 Harness 越来越厚、越来越慢、越来越贵，但没人能说清哪些部分还在承重。把行动接口当成临时代码——结果是每次模型升级都要重新对接现实世界，模型跑得更快了但手脚总是新的、没测试过的、不可靠的。

Harness 审计：三个问题替代一个

传统的 Harness 审计只问一个维度：这个组件还有用吗？更好的审计问三个：

  1. 这个组件是思维补偿还是行动接口？
  2. 如果是思维补偿——当前模型的能力是否已经跨过了它的存在前提？
  3. 如果是行动接口——重建成本是否已经低到不值得维护当前实现了？

三种决策：拆除、保留、重建。 对应的是三件不同的事——不是因为它们"做错了"，而是因为它们在不同层面运作。

Anthropic 拆 Sprint 时做的是拆除。Prithvi 保留 Sprint Contract 时做的是保留（Contract 是架构性组件——"两个 Agent 在动手前先协商验收标准"这个实践本身有价值，和模型能力无关）。团队在脚本适配器上用生成替代手写时做的是重建。

同一个 Harness 里三种决策同时发生。

两种姿态，同一种判断力

Build to Delete 和 Build to Last 不是对立的设计哲学。它们是同一个系统在不同层面的设计姿态——取决于你面对的是模型的大脑，还是现实世界的手脚。

知道哪个会过期、哪个会留下来、而"会留下来"的那个什么时候也该重建了——这是 Agent 时代最稀缺的判断力。

好消息是判断的前提可以学：先分类。在加任何组件之前，问自己它为什么存在——是因为模型还不够好，还是因为模型永远需要一个接口？两个答案导向两种完全不同的设计。

这回到了 无序 Vibe Coding 的隐性代价 中讨论过的线索：机械性的编码正在被自动化，剩下的是判断力。Build to Delete 和 Build to Last 的区分就是这种判断力的一个具体操作——它不是哲学，是每天早上坐下设计系统时可以用上的框架。

参考